ASM- Probleme mit dem Abspeichern

← Zurück zum Forum

Ich habe gerade ein Problem, wo ich nicht weiterkomme. Eine Datei, die ich problemlos öffnen und lesen kann, möchte ich nun auch wieder beschreiben. Dazu nutze ich folgenden Code (von @Dietrich) zum Öffnen der entsprechenden Datei:

    ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
    lda #3
    sta iccmd,x     ; CIO-Kommando 3 = Open
    lda <fname
    sta icadr,x     ; icadr muss auf fname ziegen
    lda >fname
    sta icadr+1,x
    lda #8          ; AUX1=4 für Open read (8 für write, 12 für update)
    sta icaux,x
    jsr ciov        ; CIO aufrufen
    bmi error       ; Returncode prüfen (steht in Y und icsta)
    rts
error
    sty 712 ;Fehler auch "sehen können"
    jmp *

Dateiname ist dieser und er funktioniert auch ohne Probleme beim Laden aus der Datei:

fname   .byte "D1:SCORES",eol           ;filename to operate with

Egal, ob ich nun @Dietrich´s uDOS oder DOS 2.5 nehme, es kommt schon hier beim Öffnen für write der Fehler 130 (NOT EXISTENT DEVICE) Muss man doch mehr machen um eine Datei zum Schreiben zu öffnen als nur die #4 nach #8 zu ändern vor sta icaux,x? Ach so, auch das Öffnen eines 2. Kanals zum Schreiben hat nichts gebracht, auch nicht, gleich am Anfang mal statt zum Lesen, zum Schreiben zu öffnen - immer ERROR 130. Anfangs dachte ich der Dateiname wäre schuld, da ich nur D: dort stehen hatte, D1: bringt aber auch nichts.

Edit: Ach so, kanal ist natürlich definiert (=1), genauso, wie alle Systemadressen.

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Fehlt da nicht ein #?

lda <fname
lda >fname

lda #<fname
lda #>fname
AntwortZitat

DjayBee schrieb: Fehlt da nicht ein #?

lda fname

lda #fname

Wie ich vermutet und auch eigentlich immer erlebt habe, ist es das nicht. MADS setzt definitiv beide Male den korrekten LDA Befehl ein ($a9). Diese low/high mnemonic kann man da also definitiv ohne # nutzen und es wird immer so assembliert.

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Wär zu einfach gewesen.

Schau doch in Altirra mal, was CIO denn tun soll/will.

.tracecio on

AntwortZitat

Sieht OK aus (abgesehen von lda <fname - diese Syntax finde ich echt schräg). Ich vermute mal eine MADS-Besonderheit. Oder das DOS ist nicht richtig initialisiert (kann aber nicht sein, wenn derselbe Code mit AUX1=4 funktioniert). Poste mal den assemblierten Hexcode (a9 01 8d 00 06 usw.) - oder ein Screenshot des Debug-Assembler-Fensters in Altirra oder hänge das XEX an oder ein ATR mit dem assemblierten XEX.

Edit: Was für einen Emulator verwendest du? Gibt der evtl. Error 130 statt Error 144 zurück, wenn das ATR (als Datei oder im Emulator) schreibgeschützt ist?

AntwortZitat

Der Emulator ist Altirra. Das atr habe ich extra mit r/w also komplett offen "eingelegt". Standard ist da normal vrw wo er am Ende fragt, ob man das atr aktualisieren möchte.

Fahre jetzt zur Arbeit. Heute Abend kann ich mit code dienen.

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Du hast vergessen ICBLEN auf die Länge des Dateinamens zu setzen (ohne das eol) also 9.

LG Lars

AntwortZitat

Nein, das CIO interessiert sich nicht für icblen beim open. Error 130 kommt, wenn das CIO das per icadr angegebene Gerät in hatabs nicht findet. Diese Suche findet bei 59154=$E712 statt (Original-XL-OS v2). Da könnte man einen Breakpoint setzen. Wenn der Fehler an dieser Stelle entsteht, ist entweder icbalz=$24/25 nicht richtig gesetzt (sollte Inhalt von icadr,x/icadr+1,x haben) oder in hatabs=$31A ist das Gerät "D" nicht vorhanden. Ansonsten fällt mir als Ursache nur ein, dass der Assembler nicht richtig wie erwartet assembliert oder in Altirra irgendwo eine Besonderheit für D: oder das CIO gesetzt ist.

AntwortZitat

Evtl. ein SIO Patch in Altirra.

Aber daher kam mein Vorschlag, CIO in Altirra zu tracen (.tracecio on im Altirra Debugger). Dann sieht man wenigstens, was der Atari "meint, tun zu müssen".

Wenn er das Richtigen meint, ist es vermutlich irgendwas im Altirra. Wenn er etwas Falsches meint, dann liegt's am Aufruf von pps.

AntwortZitat

Mal ganz naiv aus BASIC-Sicht gefragt: hast du den Kanal auch wieder geschlossen? (Das würde aber nicht den Fehler 130 erklären)

http://fujiama.eu https://abbuc.de/~atarixle/ BOSS-X - das Finale: https://abbuc.de/~atarixle/?article=bossxfinaleditionprerelease

AntwortZitat

LarsImNetz schrieb: Du hast vergessen ICBLEN auf die Länge des Dateinamens zu setzen (ohne das eol) also 9.

LG Lars

OK, das teste ich gleich mal. Komisch, dass das beim Öffnen zum Lesen scheinbar nicht stört.

Der Emulator ist es aber zu 100% nicht, da das Problem. Auch am 600XL da ist.

Auch habe ich den Kanal nach dem Öffnen zum Lesen wieder geschlossen😉

Edit: icblen setzen hat nichts gebracht.

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Hier mal der Code mitsamt dem Hexcode, der erzeugt wird:

                ;------------
                .proc open_read
                ; Datei für Lesen (AUX1=4) auf Kanal 1 öffnen: open #1,4,0,"D:NAME"
                ; für Schreiben (AUX1=8) und Update (AUX2=12) genauso
   A2 10            ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
   A9 03            lda #3
   9D 42 03         sta iccmd,x     ; CIO-Kommando 3 = Open
   A9 9D            lda #<fname
   9D 44 03         sta icadr,x     ; icadr muss auf fname ziegen
   A9 39            lda #>fname
   9D 45 03         sta icadr+1,x
   A9 04            lda #4          ; AUX1=4 für Open read (8 für write, 12 für update)
   9D 4A 03         sta icaux,x
   20 56 E4         jsr ciov        ; CIO aufrufen
   30 01            bmi error       ; Returncode prüfen (steht in Y und icsta)
   60               rts
            error
   8C C8 02         sty 712
   4C 6F 3A         jmp *
                ;   rts
                .endp
                ;------------
                .proc open_save
                ; Datei für Lesen (AUX1=4) auf Kanal 1 öffnen: open #1,4,0,"D:NAME"
                ; für Schreiben (AUX1=8) und Update (AUX2=12) genauso
   A2 10            ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
   A9 03            lda #3
   9D 42 03         sta iccmd,x     ; CIO-Kommando 3 = Open
   A9 9D            lda #<fname
   9D 44 03         sta icadr,x     ; icadr muss auf fname ziegen
   A9 39            lda #>fname
   9D 45 03         sta icadr+1,x
   A9 08            lda #8          ; AUX1=4 für Open read (8 für write, 12 für update)
   9D 4A 03         sta icaux,x
   A9 09 8D 48 03       mva #9 iclen
   20 56 E4         jsr ciov        ; CIO aufrufen
   30 01            bmi error       ; Returncode prüfen (steht in Y und icsta)
   60               rts
            error
   C0 83            cpy #131
   F0 05            beq @+
   84 95            sty cbak
   4C C5 3A         jmp *
   60           @   rts
                .endp

open_read erzeugt keine Fehler, die Datei wird danach auch korrekt gelesen. Am close kann es auch nicht liegen, denn wenn ich open_save zuerst aufrufe, kommt auch immer der Fehler. Ich stehe also weiterhin auf dem Schlauch 🙄

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

fname .byte "D:SCORES" fehlt da noch. (Und die Adressen, an die es assembliert wurde.) Sieht ansonsten OK aus. Sonst hänge mal ein ATR an, wo man den Fehler reproduzieren kann. Das kriegen wir bestimmt raus.

AntwortZitat
 44 31 3A 53 43 4F 52 45 53 9B      fname   .by "D1:SCORES",eol         ;filename to operate with

Das steht direkt bei $399D.

Eine Diskette zum Testen erstelle ich dann morgen. Will nicht schon vor dem release ein Programm veröffentlichen... Zum Testen sollte ja eigentlich ein "dummy" Programm genügen.

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Sieht OK aus. Habe das Programm gerade unter DOS 2.5 mit dem Synassembler eingetackert. Funktioniert! Klar, ein Testprogramm reicht. Jetzt bin ich aber echt gespannt, woran es liegt ...

AntwortZitat

Ich muss für heute Schluss machen. Morgen geht's wieder früh raus.

Ich habe aber eben nochmal das direkt bei Programmstart versucht - da ist wirklich nichts an Code vorher gestartet. Dort kommt Error 129 - selbst wenn ich vor open_save noch close_file starte:

;------------
    .proc close_file
; Kanal schließen
    ldx #kanal*16   ; Kanalnr. * 16 in X-Register setzen
    lda #12
    sta iccmd,x     ; CIO-Kommando 12 = Close
    jsr ciov
    bmi error       ; will man eigentlich nur beim Schreiben prüfen
    rts
error
    sty 712
    jmp *
;   rts
    .endp

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Ganz doof gefragt: Verwendest du ein Game- oder Mini-Dos, das nicht schreiben kann?

wegduck-und-renn

AntwortZitat

uDOS hatte ich zuerst, jetzt DOS 2.5

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Ups, Error 129, bevor irgendwas passiert?! Da kommt mir ein Verdacht: Überschreibst du Page 3 (beim Laden)? Der Error 129 kommt, wenn $340,x (also $350 für Kanal #1) nicht $ff ist. Und Error 130, wenn der Bereich ab $31A überschrieben wird ...

AntwortZitat

MADS distinguishes between single quotes (ATASCII coding) and double quotes (INTERNAL coding), whereas XASM treats both forms the same (ATASCII coding). Of course, the quote types are treated the same in DTA by MADS

Du musst einfache Anführungszeichen nehmen.

Visit https://www.wudsn.com the home of WUDSN IDE.

AntwortZitat

JAC! schrieb: Du musst einfache Anführungszeichen nehmen.

Ja. Das hate ich auch schon mal. Aber ein schneller Test heute früh von dem Weg zur Arbeit, wo ich das zurück geändert habe, brachte den selben Fehler 🤔 Ich schaue aber später nochmal in Ruhe (wahrscheinlich erst morgen, da heute Abend nochmal Fußball ansteht), ob ich früh doch was falsch gem8 habe.

Dietrich schrieb: Ups, Error 129, bevor irgendwas passiert?! Da kommt mir ein Verdacht: Überschreibst du Page 3 (beim Laden)? Der Error 129 kommt, wenn $340,x (also $350 für Kanal #1) nicht $ff ist. Und Error 130, wenn der Bereich ab $31A überschrieben wird ...

Das klingt interessant. Aber mein Programm belegt extra keine Bereich unter $2000 mehr für DOS 2.5 (vorher hatte ich den screen und die pmg noch ab $1000.

Ha. ❗ Ich habe ja in page 0 meine ganzen zp-register... Ich schlacke die mal aus. Kann sein, dass ich zu weit gekommen bin. Ich nutze ja selber keinen stack, aber cio bestimmt... Vielleicht habe ich ja was, was garnicht mehr zp ist...

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

JAC! schrieb: Du musst einfache Anführungszeichen nehmen.

Den Verdacht hatte ich auch schon - hatten wir aber schon oben ausgeschlossen, da pps den assemblierten Code gepostet hat, der eindeutig ATASCII zeigt, was korrekt ist.

Zeropage: Da braucht das CIO ein paar Adressen (so etwa $20-$2F) und das SIO belegt auch was (so etwa $30-$4F). Definitiv frei ist $80-$FF. $00-$7F belegt das OS. Da sollte man nix machen, wenn man das OS (hier CIO und SIO) braucht. Oder man weiß, was man tut. Es ist i.A. kein Problem, wenn man den unteren Bereich des Stacks belegt (so etwa $100-$1A0), denn der 6502-Stack wird von $1FF abwärts benutzt.

Noch was: Machst du den OPEN in einem Programmabschnitt des XEX, den du per INIT-Adresse aufrufst? Dann ist Kanal 1 noch offen, da das DOS diesen Kanal zum Laden des XEX benutzt. Das würde den Error 129 bei Programmstart erklären (aber nicht den Error 130). Erst vor Ausführen der RUN-Adresse schließt das DOS Kanal 1 wieder.

AntwortZitat

Dietrich schrieb: Zeropage: Da braucht das CIO ein paar Adressen (so etwa $20-$2F) und das SIO belegt auch was (so etwa $30-$4F).

Meines Wissens werden die nur temporär benutzt, während(!) ein CIO-/SIO-Aufruf stattfindet. Somit könnte das Programm von pps dadurch crashen weil das OS irgendwas reinschreibt, umgekehrt darf die "unberechtigte" Verwendung dieser Adressen aber keinen Einfluss auf die SIO-/CIO-Aufrufe haben.

AntwortZitat

Ich habe eigentlich gerade per copy paste das Programm nur zum Testen der Routinen ohne alles andere drumherum bauen wollen...

Ja, was oll ich sagen - ich habe glaube ich - den Fehler gefunden. 😳 Schaut selbst:

data    .ds 11*4
;------------
fname   dta c'D1:SCORES'            ;filename to operate with
    .by eol
amount  .wo 49

Wenn man 49 Bytes lädt, aber nur 44 Bytes Platz reserviert, könnte das zu Problemen führen, wenn direkt danach irgendwas im Speicher steht... Ja, was steht denn da? Richtig "D1:SCORES" 😂 🙄 Klar, dass das Device nicht existiert, wenn man dann später speichern möchte. 😁

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

So, nun habe ich es auch ausgiebig am "lebenden Objekt" getestet. Die Funktion funktioniert. Vielen Dank für die viele Hilfe, auch wenn Ihr diesen Fehler wirklich nicht finden konntet 😂

As usual: The error sits just in front of the screen! 🙄

PP´s of STARSOFTBerlin____github|meine Webseite|Demozoo

AntwortZitat

Oh mann! Das erinnert mich daran, als ich für jemanden eine Ultraspeed-Routine geschrieben hatte und sich beschwerte, dass die Routine nicht funktioniert. Und es kam dann raus, dass er die Routine einfach mit anderen Daten überschrieben hatte ...

AntwortZitat

Tipp: Ich nutze in MADS immer .LOCAL und beziehe mich dann mit .LEN darauf. So passt es sich dynamisch an.

.local data
.ds 123123
.endl

mwa #.len data address

Visit https://www.wudsn.com the home of WUDSN IDE.

AntwortZitat

Dietrich schrieb: Oh mann! Das erinnert mich daran, als ich für jemanden eine Ultraspeed-Routine geschrieben hatte und sich beschwerte, dass die Routine nicht funktioniert. Und es kam dann raus, dass er die Routine einfach mit anderen Daten überschrieben hatte ...

😂 😂 😂 😂 😂 Wer das wohl war 🙄 Danke für deine Hilfe bei der Programmierung 😉

AntwortZitat

Noch ein Tipp, um Bereichsüberschreitungen (z.B. bei Display List/Data die 1K/4K-Grenze) zu vermeiden. Einfach per .IF abfragen, ob die Grenze eingehalten wird und wenn nicht mit .ERROR das Assemblieren mit einer Fehlermeldung abbrechen. Z.B. habe ich im Code von uDOS am Ende folgendes stehen, damit uDOS in die 3 Bootsektoren = $180 Bytes passt:

     .if * > boothead+$180
        .error "uDOS darf max. $180 Bytes = 3 Sektoren gross sein"
     .endif
AntwortZitat